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Abstract 

There is increasing awareness in the planning community that 
depending on complete models impedes the applicability of 
planning technology in many real world domains where the 
burden of specifying complete domain models is too high. In 
this paper, we consider a novel solution for this challenge that 
combines generative planning on incomplete domain mod- 
els with a library of plan cases that are known to be cor- 
rect. While this was arguably the original motivation for case- 
based planning, most existing case-based planners assume 
(and depend on) from-scratch planners that work on com- 
plete domain models. In contrast, our approach views the plan 
generated with respect to the incomplete model as a "skeletal 
plan" and augments it with directed mining of plan fragments 
from library cases. We will present the details of our approach 
and present an empirical evaluation of our method in compar- 
ison to a state-of-the-art case-based planner that depends on 
complete domain models. 



Introduction 

Most work in planning assumes that complete domain mod- 
els are given as input in order to synthesize plans. However, 
there is increasing awareness that building domain models 
at any level of completeness presents steep challenges 
for domain creators. Indeed, recent work in web-service 
composition (c.f. ([Bertoli, Pistore, and Traverso 2010t 



[Hoffmann, BertoU, and Pistore 2007 1) and work- flow man- 
agement (c.f. ( Blythe, Deelman, and Gil 2004 1) suggest 
that dependence on complete models can well be the real 
bottle-neck inhibiting applications of current planning 
technology. 

There has thus been interest in the so-called "model-lite" 
planning approaches (c.f. ( [Kambhampati 2007| ) that aim to 
synthesize plans even in the presence of incomplete domain 
models. The premise here is that while complete models 
cannot be guaranteed, it is often possible for the domain 
experts to put together reasonable but incomplete models. 
The challenge then is to work with these incomplete domain 
models, and yet produce plans that have a high chance of 
success with respect to the "complete" (but unknown) do- 
main model. This is only possible if the planner has access 
to additional sources of knowledge besides the incomplete 
domain model. 
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Interestingly, one of the original motivations for case- 
based planning was also the realization that in many do- 
mains complete domain models are not available. Over years 
however, case-based planning systems deviated from this 
motivation and focused instead on "plan reuse" where the 
motivation is to improve the performance of a planner oper- 
ating with a complete domain model. In this paper, we return 
to the original motivation by considering "model-lite case- 
based planning." In particular, we consider plan synthesis 
when the planner has an incomplete domain theory, but has 
access to a library of plans that "worked" in the past. This 
plan library can thus be seen as providing additional knowl- 
edge of the domain over and above the incomplete domain 
theory. 

Our task is to effectively bring to bear this additional 
knowledge on plan synthesis to improve the correctness of 
the plans generated. We take a two stage process. First, we 
use the incomplete domain model to synthesize a "skeletal" 
plan. Next, with the skeletal plan in hand, we "mine" the 
case library for fragments of plans that can be spliced into 
the skeletal plan to increase its correctness. The plan im- 
proved this way is returned as the best-guess solution to the 
original problem. We will describe the details of our frame- 
work, called ML-CBP and present a systematic empirical 
evaluation of its effectiveness. We compare the effective- 
ness of our m odel-lite case-based planner with OAKPlan 
jSerina 2010b . the current state-of-the-art model-complete 
case-based planner. 

We organize the paper as follows. We first review related 
work, and then present the formal details of our framework. 
After that, we give a detailed description of ML-CBP algo- 
rithm. Finally, we evaluate ML-CBP in three planning do- 
mains, and compare its performance to OAKPlan. 

Related Work 

As the title implies, our work is related both to case- 
based planning and model-lite planning. As mentioned in 
the introduction, our work is most similar to the spirit 
of original case-based planning systems such as CHEF 
dHammond I989] l and PLEXUS dAlterman 1986l l, which 
viewed the case library as an extensional representation 
of the domain knowledge. CHEF's use of case modifica- 
tion rules, for example, serves a similar purpose as our 
use of incomplete domain models. Our work however dif- 
fers from CHEF in two ways. First, unlike us, CHEF as- 



sumes access to a (more) complete domain model during 
its debugging stage. Second, CHEF tries to adapt a spe- 
cific case to the problem at hand, while our work expands 
a skeletal plan with relevant plan fragments mined from 
multiple library plans. The post-CHEF case-based plan- 
ning work largely focused on having access to a from- 
scratch planner operating on complete domain models (c.f. 



( [Kambhampati and Hendler 1992[ |\^loso et al. 19"95]l). Th e 
most recent of this line of work is OAKPlan jSerina 201 Oi l, 
which we compare against. 

The recent focus on planning with incomplete domain 
models originated with the work on "model-lite planning" 
(Kambhampati 2007 1. Approaches for model-lite planning 
must either consider auxiliary knowledge sources or de- 
pend on long-term learning. While our work views the case- 
library as the auxiliary knowledge source, work by Nguyen 
et al. (Nguyen, Ka mbhampati, and Do 2010 1 and Weber et. 
al. ( Bryce and Weber 201 1 1 assume that domain writers are 



able to provide annotations about missing preconditions and 
effects. It would be interesting to see if these techniques can 
be combined with ours. One interesting question, for exam- 
ple, is whether the case library can be compiled over time 
into such possible precondition/effect annotations. 

A third strand of research that is also related to 
work is that of action model learning. Work 
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as ( Yang, Wu, and Jiang 2007 



Zettlemoyer, Pasula, and Kaelbling 2005 1 focuses on learn- 



ing action models directly from observed (or pre-specified) 
plan traces. The connection between this strand of work and 
our work can be seen in terms of the familiar up-front vs. 
demand-driven knowledge transfer: the learning methods 
attempt to condense the case library directly into STRIPS 
models before using it in planning, while we transfer 
knowledge from cases on a per-problem basis. Finally, in 
contrast, work such as (Amir 2005), as well as much of 
the reinforcement learning work dSutton and Barto 19981 ) 
focuses on learning models from trial-and-error executiorQ 
This too can be complementary to our work in that execu- 
tion failures can be viewed as opportunities to augment the 
case-library (c.f. ( Ihrig and Kambhampati 1997) l). 



Problem Definition 

A planning problem can be described as a triple P = 
(S, so,.g), where sq is an initial state, g is a goal, and S 
is defined by S = {S, A, 7), where S' is a set of states, 
^ is a set of action models, and 7 is a transition func- 
tion defined by 7 : S* x ^ — !■ S*. A solution to a plan- 
ning problem is an action sequence (or a plan) denoted by 
(ai, a2, . . . , a„), where is an action. An action model is 
defined as (a, PRE(a), ADD(a), DEL(a)), where a is an ac- 
tion name with zero or more parameters, PRE(a) is a pre- 
condition list specifying the condition under which a can be 
applied, ADD(a) is an adding list and DEL(a) is a deleting 
list indicating the effects of a. No tice that we focus on the 
STRIPS action model description dFikes and Nilsson 19711) 
in this paper. An action model a is called "incomplete" 
when there are predicates missing in PRE(a), ADD(a), or 
DEL(a). A set of incomplete action models is denoted by 



A. An incomplete planning problem is denoted by P = 
{sQ,g,A). Apian examplepis composed by an initial state, 
a goal and an action sequence that transits the initial state 
and the goal, i.e., p = (so,ai, . . . ,an,g), where sq is the 
initial state, ai is an action, and g is the goal. We denote a 
set of plan examples by E. 

Our planning problem in this paper is defined by: given as 
input a quadruple {so,g, A, E), where sq is an initial state, 
and g a goal, as described above, ^ is a set of incomplete 
action models, and _E is a plan example set, our ML-CBP 
algorithm outputs a solution that transits sq and g. 

An example input of our planning problem in blocL^ do- 
main is shown in FigurelT] which is composed of three parts: 
incomplete action models (Figure [TJ a)), an initial state sq 
and a goal g (Figure Hlb)), and a plan example set (Fig- 
ure [He)). In Figure \lla), the dark parts indicate the miss- 
ing predicates. In Figure [TJc), pi and p2 are two plan ex- 
amples, where initial states and goals are bracketed. An ex- 
ample output is a solution to the planning problem given in 
Figure[Tl i.e., "unstack(C A) putdown(C) pickup(B) stack(B 
A) pickupi C) stack( C B) pickup(D) stack(D C)". 

Our ML-CBP Algorithm 

Algorithm 1 Our ML-CBP algorithm 

Input: P = {so,g, A), and a set of plan examples E. 
Output: the plan p'*"' for solving the problem. 

1: generate a set of causal pairs I with P; 
2: build a set of plan fragments ip: 

ip=buildjragments{l, E); 
3: mine a set of frequent plan fragments J': 

J-=freqjnining{ip); 

/, T, P) = true then 



if concatjragip^"^ . 

return p""'; 
else 

return NULL; 
end if 



An overview of our ML-CBP algorithm can be found in 
Algorithm[T] We first generate a skeletal plan, presented by 
a set of causal pairs, based on (sq, 3, A). After that, we build 
a set of plan fragments based on plan examples and causal 
pairs, and then mine a set of frequent plan fragments with 
a specific threshold. These frequent fragments will be in- 
tegrated together to form the final solution p^°^ based on 
causal pairs. Next, we describe each step in detail. 

Generate causal pairs 

Given the initial state sq ™d goal g, we generate a set of 
causal pairs I. A causal pair is an action pair {ai,aj) that 
Qi provides one or more conditions for Uj. The procedure 
to generate I is shown in Algorithm |2] Note that, in step 3 
of Algorithm m I' is an empty set if p cannot be achieved. 
In other words, skeletal plans may not provide any guidance 
for some top level goals. Actions in causal pairs I is viewed 



'This latter has to in general be limited to ergodic domains 
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pickup (?x - block) 

pre: (handempty) (clear ?x) (ontable ?x) 
eff: (holding ?x) (not (handempty)) 

(11(11 (cle;!i" 'x)! (not (ontable ?x)) 
putdown (?x - block) 
pre: (holding ?x) 

eff: (ontable ?x) (clear ?x) (handempty) 

(not (holding ?x)) 
unstack (?x ?y - block) 
pre: (handempty) (on ?x ?y) (clear ?x) 
eff: (holding ?x) (clear ?x) (not (clear ?x)l 

(not (on ?x ?y)) (not (handempty)) 
stack (?x ?y - block) 
pre: (clear ?yi (holding ?x) 
eff: (on ?x ?y) (clear ?x) (handempty) 

(not (clear ?y)) ino( (hokiing ','x)) 
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.So: (on C A) 
(ontable A) 
(clear C) 
(ontable B) (ontable D) 
(clear B) (clear D) (handempty) 

(b). Initial state so and goal g 



g: (on D C) 

(onCB) _C_ 
(onBA) ^ 



Pi: {(clear bl) (clear b2) (clear b3) (clear b4) (ontable bl) 
(ontable b2) (ontable b3) (ontable b4) (handempty)), pickup(b3) 
stack(b3 b2) pickiip(bl) stack(bl b3) pickup(b4) stack(b4 bl), 
{(on b4 bl) (on bl b3) (on b3 b2)) 

P2: {(clear- bl) (ontable b2) (on bl b3) (on b3 b2) (handempty)), 
unstack(bl b3) putdown(bl) unstack(b3 b2) putdown(b3) 
pickup(bl) stack(bl b2) pickup(b3) stack(b3 bl), {(on b3 bl) 
(on bl b2)) 
pf. ... 



(a). Incomplete action models 



(c). Plan examples 



Figure 1; An input example of the ML-CBP algorithm for the blocks domain 



Algorithm 2 Generate causal pairs 

input: initial state sq, goal g, incomplete action models A. 
output: a set of causal pairs I. 
1: / = 0; 

2: for each proposition p e g do 

3: generate a plan, denoted by a set of causal pairs to 

transit sq to p; 
4: l^l{M'\ 
5: end for 
6: return l\ 



as a set of landmarks for helping construct the final solution, 
as will be seen in the coming sections. We show an example 
of the generated causal pairs in Example 1 . 
Example 1: As an example, causal pairs generated for the 
planning problem given in Figure\l\is {{pickup(B),stack(B 
A)), ( unstack(CA), stack(C B)), {pickup(D), stack(D C))}. 

Creating Plan Fragments 

In the procedure "build fragments" of Algorithm [T] we 
would like to build a set of plan fragments ip by building 
mappings between "objects" in {so,g) of P and (soi.9*) of 
a plan example pi G E. In other words, a mapping, denoted 
by m, is composed of a set of pairs {(o', a)}, where a' is 
an object (i.e., an instantiated parameter) from plan example 
Pi, and o is an object from P. We can apply mapping m to a 
plan example pi, whose result is denoted by pi\m, such that 
Sq|,„ and Sq share common propositions, likewise for g' and 
g. We measure a mapping m by the number of propositions 
shared by initial states Sg|m and sq, and goals 5* and g. We 
denote the number of shared propositions by X{pi,m), i.e., 

A(p,,?7i) = |(s^|„o n Sol + Ks'lm) n.g|. 

An example to demonstrate how to calculate A is given as 
follows. 

Example 2: In Figure [7] a possible map- 
ping m between {sQ,g) and (sg^g^) of pi is 
{(64,D),(61,C),(&3,B}, (62,A)}. The result of ap- 
plying m to Sq is s},\m={(clear C)(clear A)(clear 



B)( clear D)( ontable C)( ontable A)( ontable B)( ontable 
D)( handempty)}. Likewise, we can calculate the re- 
sult of applying m to g^. It is not difficult to see that 
X{pi,m) = |(sJ|™)nso'| + |(.g^|m)n.g| = 10. 

It is possible that there are many different mappings be- 
tween P and Pi. We choose a mapping m* with the largest A 
to maximally map pi to P, i.e., m* = argmax^ X{pi,'m). 
We assume that all propositions are "equally" important in 
describing states. The more common propositions P and pi 
share, the more "similar" they are. Note that mappings be- 
tween objects of the same types are subject to the constraint 
that they should have the set of "features" in the domain, 
defined by unary predicates of the corresponding types. For 
instance, "b3" can be mapped to "B" in our running exam- 
ple since both of them are the two blocks having the same 
features "on table" and "clear" in the two problems. In prac- 
tice, we find that this requirement significantly reduces the 
amount of mappings that need to be considered, actually al- 
lowing us to find m* in a reasonable running time. 

We apply m* to pi to get a new plan example Pi\m*, 
which is denoted by {a\,a2, . ■ . , alJ. We scan the action 
sequence from ai to a„ to get subsequences that satisfies 
the constraint that all the objects in the subsequences should 
be in P. We call these subsequences plan fragments. We 
can build a set of plan fragments using plan examples E. 
Example 3: In Example 2, we find that m* = 
{{b4:,D),{bl,C),{bS,B),{b2,A)}. Thus, is 
"pickup(B) stack(B A) pickup(C) stack(C B) pickup(D) 
stack(D C)", which is a plan fragment. For p2 in Figure 
[7] m* is {(63, C), S), (62, A)}. Thus, p2\m' is "un- 
stack(B C) putdown(B) unstack(C A) putdown(C) pickup(B) 
stack(B A) pickup(C) stack(C B)", which is also a plan 
fragment. 

Mining Frequent Plan Fragments 

In step 3 of Algorithm[Tl we aim at building a set of frequent 
plan fragments F using the procedure 'freqjnining" . Given 
that there will not be any function perfectly mapping the two 
planning problems, our intuition is that a plan fragment oc- 
curring multiple times in different plan examples increases 



our confidence on both the quality of the mapping between 
objects involved and the success of reusing the fragment as 
part of a solution plan for the problem being solved. We thus 
borrow the notion of frequent patterns defined in dZaki 200T1 
IPei et al.^04j to use for mining our frequent plan frag- 
ments. The problem of mining sequential patterns can be 
stated as follows. Let X = {ii, i2, . . . , i„} be a set of n 
items. We call a subset X C I an itemset and \X\ the size 
of X. A sequence is an ordered list of itemsets, denoted by 
s = (si, S2, . . . , Sm), where sj is an itemset. The size of 
a sequence is the number of itemsets in the sequence, i.e., 
\s\ = m. The length I of a sequence s = {si, S2, ■ ■ ■ , Sm) is 
defined as I ~ J2^i ^ sequence Sa = (ai, 02, ... , a„) 
is a subsequence of another sequence Sh — (61, 62, ... , 6m) 
if there exist integers \ < i\ < ii < . . . < in < m such that 
a\ C 6ij,a2 C bi^,...,an C 6^^, denoted by Sa E si,. A 
sequence database S* is a set of tuples {sid, s), where sid is 
a sequenccid and s is a sequence. A tuple {sid, s) is said to 
contain a sequence a, if a is a subsequence of s. The support 
of a sequence a in a sequence database S is the number of 
tuples in the database containing a, i.e., 

sups{a) = \{(sid, s)\{(sid, s) G S") n (a C s)}[. 

Given a positive integer 6 as the support threshold, we call 
a a frequent sequence if sups{a) > 6. Given a sequence 
database and the support threshold, frequent sequential pat- 
tern mining problem is to find the complete set of sequential 
patterns whose support is larger than the threshold. 

We view each action of plan fragments as an itemset, and 
a plan fragment as a sequence, which suggests plan frag- 
ments can be viewed as a sequence database. Note that in 
our case an itemset has only one element, and the indices of 
those in the subsequence are continuous. We fix a threshold 
6 and use the SPADE algorithm jZaki 200 11 1 to mine a set of 
frequent patterns. There are many frequent patterns which 
are subsequences of other frequent patterns. We eliminate 
these "subsequences" and keep the "maximal" patterns, i.e., 
those with the longest length, as the final set of frequent plan 
fragments J^. 

Example 4: In Example 3, if we set 5 to be 2 and 1, the 

results are shown below (frequent plan fragments are parti- 
tioned by commas): 



Note that the following frequent patterns are eliminated 
when 5 = 2 (likewise when 5 = 1): {pickup(B), stack(B 
A), pickup(C), stack(C B), pickup(B) stack(B A), stack(B 
A) pickup(C), pickup(C) stack(C B), pickup(B) stack(B A) 
pickup( C), stack(B A) pickupi C) stack( C B)}. 



Generating Final Solution 

In steps 4-6 of Algorithm [T] we generate the final solution 
using frequent plan fragments generated by step 3. We ad- 
dress the procedure concat^rag by Algorithm [3] In Algo- 
rithmic we scan each causal pair in I and each frequent plan 
fragment in if a plan fragment contains an action (or both 
actions) of a causal pair, we append the plan fragment to the 
final solution p^°^ and remove all the causal pairs that are 
satisfied by the new ; and then recursively call the pro- 
cedure concat^rag until the solution is found, i.e., / = 0, or 
no solution is found, i.e., the procedure returns/aZse (/ 7^ 0). 



Algorithm 3 concatJ'rag(p^°\ I, T,P); 

input: a plan p^°\ a set of causal pairs I, a set of frequent 
plan fragments J", and an incomplete problem; 
output: true or false. 

1; if / = 0then 

2: = remove_first_actions{p''°\P); 

3: p'*"' = removeJast_actions{p^°^ , P); 

4: if is executable based on P then 

5: return true; 

6: else 

7: return false; 

8: end if 

9: end if 

10: for each pair (a.;, Oj) G I and each f E T do 

11: ii{at £ f V Qj e f) and shareip""'- , /) =true then 

12: p""^' =append(p'"'\ /); 

13: l'=removelinks{p''°^' , I); 

14: p^T-{f}- 

15: it concat/ragip^"^ , I', J-,P) =true then 

16: return true; 

17: end if 

18: end if 

19: end for 

20: return false 



In step 2 of Algorithm [3j we repeatedly remove the first 
action of that cannot be applied in sq. In step 3 of Al- 
gorithmic we repeatedly remove the last action of p**"' that 
deletes propositions of goal g. After steps 2 and 3, the re- 
mainder plan can be executed from sq to g using A, then 
the algorithm returns true, otherwise, returns false. In step 
11 of Algorithmic the procedure share returns true if p^°^ 
is empty orp*"' and / share a common action subsequence. 
That is to say, two plan fragments are concatenated only if 
they have some sort of connection, which is indicated by 
common action subsequence. In step 12 of Algorithmic we 
concatenate p""' and / based on their maximal common 
action subsequence, which is viewed as the strongest con- 
nection between them. Note that the common action subse- 
quence should start from the beginning of OR end at 
the end of p''°K In other words, / can be concatenated at the 
end of p'*"' or at the beginning, as is shown in Figure |2| In 
step 13 of Algorithmic the procedure removelinks remove 
all causal pairs in I that are "satisfied" by The result is 
denoted hy I'. Example 5 demonstrates how to generate final 
solutions. 



plan fragments: 

1. pickup(B) stack(B A) pickup(C) stack(C B) pickup(D) 
stack(D C) 

2. unstack(C A) putdown(C) pickup(B) stack(B A) 
pickupi C) stack( C B) 

frequent plan fragments J- (5 = 2): 
{pickup(B) stack(B A) pickup(C) stack(C B)} 
frequent plan fragments !F (5 = 1); 
{pickup(B) stack(B A) pickup(C) stack(C B) pickup(D) 
stack(D C), unstack(B C)putdown(B)unstack(C A) put- 
down(C) pickup(B) stack(B A) pickup(C) stack(C B)} 



p 



/ 



appendljj" . f) 



P 



/ 



appendip'" , f) 



(b) 



Figure 2: (a). / is concatenated at the end of (b). / is 
concatenated at the beginning of p'^°^ ; Part (I) is the maximal 
action subsequence; Part (II) is the action subsequence that 
is different from 



Example 5: In Example 4, we have two frequent plan 
fragments by setting 5 = 1. We concatenate these two 
fragments together. The result is shown as follows. The 
boldfaced part is the actions shared by fragments 1 an 
d 2. The concatenating result is shown in the third row. 
After concatenating, we can see that all the causal pairs 
in I is satisfied and will be removed according to step 13 
of Algorithm \3\ Furthermore, according to steps 2 and 
3 of Algorithm\3\ the first two actions are removed since 
they cannot be applied in sq, and no action is removed at 
the end of the plan since no action deletes propositions 
of g. The result is shown in the fourth row. The result is 
executable from so to g, which means it is the final solution. 



fragment 1: pickup(B) stack(B A) pickup(C) stack(C B) 

pickup(D) stack(D C) 



fragment 2: unstack(B C) putdown(B) unstack(C A) put- 
down( C) pickup(B) stack(B A) pickup(C) stack(C B) 



result: unstack(B C) putdown(B) unstack(C A) put- 
down(C) pickup(B) stack(B A) pickup(C) stack(C B) 

pickup(D) stack(D C) 



solution: unstack(C A) putdown( C) pickup(B) stack(BA) 
pickup(C) stack(CB) pickup(D) stack(D C) 



Experiments 
Dataset and Criterion 

We evaluate our ML-CBP algorithm in three planning do- 
mains: blocks^, driverlo^ and depots^. In each domain, we 
generate from 40 to 200 plan examples using a classical 
planner such as FF planneiQ and solve 100 new planning 
problems based on different percentages of completeness of 
domain models. For example, we use | to indicate one pred- 
icate is missing among five predicates of the domain. 

We define the accuracy of our ML-CBP algorithm as the 
percentage of correctly solved planning problems. Specifi- 
cally, we exploit ML-CBP to generate a solution to a plan- 
ning problem, and execute the solution from the initial state 
to the goal. If the solution can be successfully executed start- 
ing from the initial state, and the goal is achieved, then the 
number of correctly solved problems is increased by one. 



http://planning.cis.strath.ac.uk/competition/ 
http://members.deri.at/~joergh/ff. html 



The accuracy, denoted by A, can be computed by A = 
where Nc is the number of correctly solved problems, and 
Nt is the number of total testing problems. Note that when 
testing the accuracy of ML-CBP, we assume that we have 
complete domain models available for executing generated 
solutions. It is easy to see that the larger the accuracy A is, 
the better our ML-CBP algorithm functions. 

Experimental Results 

We would like to evaluate ML-CBP in the following as- 
pects: (1) the change of accuracies with respect to differ- 
ent number of plan examples; (2) the change of accuracies 
with respect to different percentages of completeness; (3) the 
change of accuracies with respect to different support thresh- 
old S; (4) the average of plan lengths; (5) the running time 
of ML-CBP. We compared our ML-CBP algorithm with the 
state-of-the-art CBP (Case Based Planning) system OAK- 
Plan ( ISerina 20101 1. OAKPlan requires a complete domain 
model and a case library as input for a new planning prob- 
lem. To make OAKPlan be comparable with our ML-CBP 
algorithm, we fed an incomplete domain model to OAKPlan, 
which was the same as the input of ML-CBP, instead of an 
complete domain model. 

Varying the number of plan examples We would like to 
test the change of the accuracy when the number of plan 
examples increasing. We set the percentage of completeness 
as 60%, and the threshold S as 15. We varied the number of 
plan examples from 40 to 200 and run ML-CBP to solve 100 
planning problems. We calculated the accuracy A for each 
case. The result is shown in Figure |3] 




80 120 160 200 
plan examples 



80 120 160 200 
plan examples 
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plan examples 



Figure 3: Comparison between ML-CBP and OAKPlan with 
respect to different number of plan examples. 

From Figure[3] we found that both accuracies of ML-CBP 
and OAKPlan generally became larger when the number of 
plan examples increased. This is consistent with our intu- 
ition, since there is more knowledge to be used when plan 
examples become larger. On the other hand, we also found 
that ML-CBP generally had higher accuracy than OAKPlan 
in all the three domains. This is because ML-CBP exploits 
the information of incomplete domain models to mine multi- 
ple high quality plan fragments, i.e., ML-CBP integrates the 
knowledge from both incomplete domain models and plan 
examples, which may help each other, to attain the final so- 
lution. In contrast, OAKPlan first retrieves a case, and then 
adapts the case using the inputted incomplete domain model, 
which may fail to make use of valuable information from 
other cases (or plan fragments) when adapting the case. 

By observation, we found that the accuracy of ML-CBP 
was no less than 0.8 when the number of plan examples was 
more than 160. 



Varying the percentage of completeness To test the 
change of accuracies with respect to different degrees of 
completeness, we varied the percentage of completeness 
from 20% to 100%, and ran ML-CBP with 200 plan exam- 
ples by setting 5 = 15. We also compared the accuracy with 
OAKPlan. The result is shown in Figured 



(a), blocks (b). driverlog (c). depots 
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may incur false negative, i.e., "good" plan fragments are ex- 
cluded when mining frequent plan fragments in step 3 of 
Algorithm [U In contrast, a low threshold may incm false 
positive, i.e., "bad" plan fragments are introduced. Both of 
these two cases may reduce the accuracy. We can see that 
the best choice for the threshold could be 15 (the accuracies 
of (5 = 15 and (5 = 25 are close in depots). 

Table 2: Accuracy with respect to different thresholds, 
threshold blocks driverlog depots 
g^5 0:80~ 0.78 0.73 
5 = 15 0.88 0.84 0.79 
(5 = 25 0.83 0.75 0.80 



Figure 4: Comparison between ML-CBP and OAKPlan with 
respect to different percentage of completeness. 

We found both accuracies of ML-CBP and OAKPlan in- 
creased when the percentage of completeness increased, due 
to more information provided when the percentage increas- 
ing. When the percentage is 100%, both ML-CBP and OAK- 
Plan can solve all the solvable planning problems success- 
fully. Similar to Figure |3] ML-CBP functions better than 
OAKPlan. The reason is similar to Figure[3] i.e., simultane- 
ously exploiting both knowledge from incomplete domain 
models and plan examples could be helpful. 

By observing all three domains in FigureHl we found that 
ML-CBP functioned much better when the percentage was 
smaller. This indicates that exploiting multiple plan frag- 
ments, as ML-CBP does, plays a more important role when 
the percentage is smaller OAKPlan does not consider this 
factor, i.e., it still retrieves only one case. 

Average of plan length We calculated an average of plan 
length for all problems successfully solved by ML-CBP 
when S was 15, the percentage of completeness was 60%, 
and 200 plan examples were used. As a baseline, we ex- 
ploited FF to solve the same problems using the correspond- 
ing complete domain models and calculate an average of 
their plan length. The result is shown in Table[T] 



Table 1 : Average of plan length 



domains 


blocks 


driverlog 


depots 


ML-CBP 


46.8 


83.4 


95.3 


FF 


35.2 


79.2 


96.7 



From Table [H we found that the plan length of ML-CBP 
was larger than FF in some cases, such as blocks and driver- 
log. However, it was also possible that ML-CBP had shorter 
plans than FF (e.g., depots), since high quality plan frag- 
ments could help acquire shorter plans. 

Varying the support threshold We tested different sup- 
port thresholds to see how they affected the accuracy. We set 
the completeness to be 60%. The result is shown in Table 
121 The bold parts indicate the highest accuracies. We found 
that the threshold could not be too high or too low, as was 
shown in domains blocks and driverlog. A high threshold 



The running time We show the average CPU time of our 
ML-CBP algorithm over 100 planning problems with respect 
to different number of plan examples in Figure|5] As can be 
seen from the figure, the running time increases polynomi- 
ally with the number of input plan traces. This can be ver- 
ified by fitting the relationship between the number of plan 
examples and the running time to a performance curve with 
a polynomial of order 2 or 3. For example, the fit polynomial 
for blocks is -0.0022a;2 + l.lOOTx - 45.2000. 
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plan examples plan examples plan examples 

Figure 5: The running time of our ML-CBP algorithm 



Conclusion 

In this paper, we presented a system called ML-CBP for do- 
ing model-lite case-based planning. ML-CBP is able to inte- 
grate knowledge from both incomplete domain models and 
a library of plan examples to produce solutions to new plan- 
ning problems. With the incomplete domain models, we first 
generate a skeletal plan using of-the-shelf planners, and then 
mine sequential information from plan examples to finally 
generate solutions. Our experiments show that ML-CBP is 
effective in three benchmark domains compared to case- 
based planners that rely on complete domain models. Our 
approach is thus well suited for scenarios where the planner 
is limited to incomplete models of the domain, but does have 
access to a library of plans correct with respect to the com- 
plete (but unknown) domain theory. Our work can be seen 
as a contribution both to model-lite planning, which is in- 
terested in plan synthesis under incomplete domain models, 
and the original vision of case-based planning, which aimed 
to use a library of cases as an extensional representation of 
planning knowledge. 
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